Submit Code
The IAEA intends to create a list of open-source codes to provide the member countries with an outlook of available tools and facilitate collaboration among their institutions. The code can be on your own repository, or IAEA can also support in providing space.
Institutions that are interested in listing a code in the webpage, can do so by filling the code template [1]. They are encouraged to consult the code contribution guidelines given below to confirm the proposed code is in-line with the objectives of the ONCORE initiative.
The template should be filled completely and in details to allow availability of sufficient information for consideration. Please note if the code is listed on the website, the completed form will also be made public.
[1] Template for Code description in the frame of the IAEA ONCORE initiative
Guidelines for code contribution
The IAEA intends to create a list of open-source codes for nuclear reactor analysis to provide the member countries with an outlook of available tools. This document provides recommended guidelines that code developers are expected to follow for their codes to be considered for inclusion in the list. The guidelines reported below have partly been derived from the reviewing guidelines of the Journal of Open-Source Software[1].
Software license
There should be an OSI approved[2] license included in the repository. Common licenses such as those listed on https://opensource.org/licenses/category are preferred. Note that there should be an actual license file present in the repository and not just a reference to the license. As an example, one can include a plain-text LICENSE file with the contents of an OSI approved license. A simple phrase such as 'MIT license' in a README file is instead not acceptable.
The software must be cost free for users and developers.
Documentation
There should be sufficient documentation for a user to understand the core functionalities of the software. A high-level overview of this documentation should be included in a README file (or equivalent).
Expected minimum requirements include:
- A statement of need: the authors should clearly state what problems the software is designed to solve and who the target user is. If adequate, the authors can also clarify the limitations of their software to avoid misuse.
- Installation instructions: the software should include detailed step-by-step instructions for installation.
- Dependencies: there should be a clearly stated list of dependencies.
- Third-party tools: the software should include all tools, or reference to all tools, that are necessary to its use.
- Methodology: the software should include enough documentation (or reference to documentation) for a user to understand the mathematical models employed, and their specific implementation in the software.
- Commented examples and tutorials should be included to enable a user to understand the various entries and input files.
- Publications: the software must have been used for at least one peer-reviewed publication. A reference to said publication should be provided.
- Verification: the software should include sufficient documentation (or reference to documentation, publications, reports, etc.) to support a basic verification of its functionalities.
In addition, developers are encouraged to implement the following recommendation:
- Include a user manual, for instance in the form of a .pdf file, wiki page, or other website.
- Include a theory manual, for instance in the form of a .pdf file, wiki page, or other website.
- Dependencies should be handled with an automated package management solution.
- All third-party tools should be open source.
- All essential documentation should be open access.
- Core API functionalities should be documented, and specific use properly commented in the code.
- The repository should contain clear guidelines for third parties wishing to contribute to the software, report issues or problems with the software, and seek support.
Examples and tutorials
The authors are expected to include examples of how to use the software, ideally to solve realistic analysis problems. The examples should cover the essential functionalities of the code. In case the examples require running the code multiple times, or running multiple tools, it is recommended to include an automated “Allrun" script (for instance in bash) that executes these different steps.
Tests
Authors are strongly encouraged to include an automated test suite covering the core functionalities of their software. An automated test suite connected to an external service is ideal. Otherwise, one should provide documented manual steps that can be followed to objectively check the expected functionality of the software (e.g., a sample input file to assert behavior).
Maintenance
- The code must have been maintained and developed for at least 24 months.
- The code must be functional.
- The developers are expected to commit for long-term maintenance (e.g., 2-yr or more). The expert group will regularly check the list and in case code is not in active and required maintenance or support, it will be removed from the list.
Export authorization
The software must not be subject to export control regulation in the country from where it is released.
[1] https://joss.readthedocs.io/en/latest/review_criteria.html#review-items
[2] https://opensource.org/licenses/alphabetical
